Rstudio est un éditeur de code (IDE) très complet, le plus intégré à l’éco-système R:
RR markdown: documents LateX, html, livres…Python,C++…)git, visualiser du html, des shiny…L’interface a l’aspect suivant1:
La fenêtre source: fenêtre où on édite les programmes et fichiers texte.
La fenêtre console: fenêtre où le code édité s’exécute. On peut également écrire directement dans la console pour exécuter du code.
Files/Plots/….
?sumEnvironment/History/…..
RR et d’autres systèmes, par exemple serveur SQLPour qu’un programme soit reproductible, le contexte doit être homogène, c’est-à-dire que tout utilisateur doit être en mesure de faire tourner l’intégralité du programme sans erreur. C’est une philosophie assez exigeante mais qui, lorsqu’on l’a à l’esprit, permet de développer un code propre et clair facilitant une évolution future (le code ne doit jamais être vu comme une production figée).
Les projets Rstudio sont un outil pour faciliter la collaboration mais aussi mieux s’organiser lorsqu’on travail en solitaire. Un projet bien organisé facilite la vie:
Faciliter des évolutions postérieures avec un projet organisé
R:
La philosophie des Rproject est d’associer à chaque projet personnel un contexte
.R mais un ensemble plus globalPar exemple, le package ci-dessous est organisé de manière à ce que les codes (R) soient associés à une documentation propre à chaque fonction (man) et à une documentation plus globale (inst). L’organisation des packages sera abordée plus en détail par la suite. Ce package est lui-même inclus dans un projet plus large où il est appelé par des Rmarkdown qui me permettent de construire des productions écrites intermédiaires et finales
Exemple de RProject (ici sous forme de package)
Créer un nouveau projet: File > New Project
3 possibilités:
Rstudio facilite l’initialisation de différents types de projets. Cela permet d’avoir une organisation cohérente avec le besoin: écrire un article/livre avec R ne demande pas la même organisation de programmes qu’une chaîne de production
Différents types de projets
On peut tout à fait avoir des projets emboîtés si c’est nécessaire. Par exemple, une organisation fréquente d’un dossier est
Les projets sont une forme très malléable d’organisation et s’adaptent ainsi facilement à des besoins hétérogènes. Ils sont néanmoins recommandés, à défaut de pouvoir les rendre obligatoire, pour travailler en équipe où la définition d’un contexte commun est primordial
git ?Un outil supplémentaire pour assurer la sécurité du code est le contrôle de version. Cela permet de stocker un code, et l’ensemble de ses évolutions, sur un serveur distant. Par exemple, le projet ci-dessous,
Un exemple de projet sauvegardé
est entreposé sur un dépôt. Il en existe des publics (gitlab,github,framagit) et des dépôts à accès restreints (ex: plateforme innovation). Le principal intérêt de la gestion de version est que, ligne par ligne, on peut suivre les évolutions d’un fichier. En conséquence, plus besoin de stocker 20190513_toto.R et 20190514_toto.R: on aura un seul fichier toto.R dont on peut suivre les version.
Le principal logiciel de gestion de version est git, sur lequel nous reviendrons. On peut initialiser git en même temps que le projet
To git or not to git?
RProject: structure.Rproj dans le dossier principal.
Structure d’un projet R
RProject: structure.Rproj.user)
.Rbuildignore, .gitignoreStructure d’un projet R
RProject: structureRstudio et affiche son nom dans la barre de projetsRaccourci pour accéder aux derniers projets
Lorsqu’on ouvre un Rproject:
R est ouverte.Rprofile du projet (si présent) est chargé.RData du projet (si présent) est chargé (si les options du projet l’autorisent).Rhistory du projet (si présent) est chargé dans le cadre History (et permet l’utilisation des boutons haut/bas pour remonter l’histoire des commandes). RstudioRStudio (e.g. position du curseur, etc.) sont restaurés à leur valeur précédent la fermeture du projet.RData et/ou .Rhistory sont sauvegardés dans le projet (si les options du projet l’autorisent)Tools > Project Options...)(Default): utiliser les options globales.Rhistory dans le fichier .gitignore (si existe) si l’histoire des commandes est conservéeOptions générales
build (développement package uniquement)C’est l’endroit où on peut définir les options de compilation du package. Nous reviendrons dessus plus tard. Il est recommandé de cocher les cases
RoxygenOn peut ajouter des options à la compilation. Par exemple, pour gagner du temps, on pourra utiliser l’option --no-build-vignettes qui évite de re-compiler les vignettes (qui peuvent mettre du temps à compiler si elles sont longues)
Exemple d’options pour les packages
gitExemple d’options git
RstudioPour gagner du temps, il est important d’utiliser les raccourcis pour les commandes répétitives. En voici quelques uns,
Ctrl+Enter: exécuter les lignes sélectionnéesTab: autocomplétionCtrl + Alt + R: exécuter l’ensemble d’un scriptCtrl + I: réindenter codeCtrl + Shift + A: reformater codeAlt + Up/Down: déplacer une ligne sans faire copier-collerCtrl + Deplacement souris: passage en édition verticale (curseur en colonne)Ctrl + Shift + M: insérer pipe %>%Alt+ 6 (windows): insérer opérateur assignation <-Ctrl + Shift + F: rechercher une expression dans plusieurs fichiersCtrl + Shift + K: compilation d’un markdown (knitter en bon français)Une fonction peut provoquer une erreur parce que
stop pour éviter l’exécution d’une erreur dans des conditions que l’on n’avait pas anticipé. C’est très utilisé en programmation défensive, paradigme de programmation où on essaie d’assurer le fonctionnement continu d’un programme, en faisant en sorte qu’un code échoue dans une manière pré-determinée même si l’origine de l’erreur ne pouvait pas être anticipée lors de la conception. Un des principes clés de ce paradigme est “l’erreur rapide”: dès qu’on remarque une potentielle erreur, on la signale. Cela implique plus de travail pour le programmeur mais rend le débuggage, et donc la collaboration, plus efficace car les utilisateurs peuvent identifier et isoler l’origine de l’erreur et ainsi la corriger plus rapidement.Par exemple, si on ne connaît pas le fonctionnement de la fonction log, et donc ne saît pas qu’elle fonctionne (mais renvoie un NaN) avec des nombres négatifs, on peut une pratique de programmation défensive et écrire
lance_erreur <- function(x){
if (x<=0) stop("J'ai peur que les nombres négatifs provoquent une erreur")
return(log(x))
}
lance_erreur(2)
## [1] 0.6931472
lance_erreur(-2)
## Error in lance_erreur(-2): J'ai peur que les nombres négatifs provoquent une erreur
La programmation défensive n’est pas une pratique obligatoire en équipe, il s’agit d’un principe de prudence.
On peut utiliser trois outils pour débugger:
traceback() qui liste la séquence des appels qui a amené une erreuroptions(error = browser) permettant d’ouvrir une fenêtre interactive pour tester l’environnement ayant généré l’erreurbrowser() qui ouvre une session sur un point déterminé par le créateur de la fonctionCet outil est parfois appelé call stack. Il permet de voir l’empilement d’appels de fonctions ayant généré l’erreur.
Par exemple, voici une séquence ayant générant une erreur
f <- function(a) g(a)
g <- function(b) h(b)
h <- function(c) i(c)
i <- function(d) "a" + d
f(10)
En cliquant sur le bouton traceback, on voit la séquence de fonctions, ce qui permet d’identifier que l’origine de l’erreur provient de la fonction i(.):
S’il s’agit d’un code qui a été lu à partir de la commande source(), le traceback affichera également la localisation de la fonction dans le fichier sous la forme filename.r#linenumber. On peut cliquer dessus et Rstudio amènera à la localisation du fichier dans l’éditeur
traceback() montre la manière dont l’erreur s’est produite, pas pourquoi. Cliquer sur le bouton “Rerun with debug” permet d’ouvrir une fenêtre interative qui permet de mettre en pause l’exécution d’une fonction et explorer interactivement l’état de celle-ci.
C’est particulièrement intéressant car une source fréquente d’erreur provient du fait que, lorsqu’on développe généralement un code, on interagit avec l’environnement global alors que les fonctions exécutent leur code interne dans un environnement séparé. Le debuggeur permet d’interagir avec ces environnements, de s’assurer que l’environnement accède bien aux objets désirés (packages, paramètres, dataframe, functions…), que les environnements emboîtés accèdent bien aux objets attendus…
Vous verrez apparaître le code correspondant dans l’éditeur, avec la prochaine commande mise en lumière. Les objets présents dans les environnements d’exécution des différentes fonctions emboîtées sont disponibles: on peut naviguer dedans.
On dispose également d’une barre dans la console:
print(n) (dans le debuggeur, n est un raccourci pour next).On peut mettre un point d’arrêt à une fonction en cliquant sur la gauche du numéro de ligne d’un script (ou Shift + F9 quand on a le curseur sur la ligne) ou bien browser() dans le code de la fonction à l’endroit où on désire l’arrêter. Une fois placé, quand on exécutera la fonction, on aura le debuggeur qui s’ouvrira une fois arrivé à cet endroit
Les addins sont des outils pratiques pour gagner du temps dans l’édition du code
install.packages('addinslist')CRAN sont disponibles pour tous, ceux sur github nécessitent d’avoir configuré le proxyLes addins sont disponibles en haut de l’éditeur
Addins Rstudio
Avec le package addinslist, on peut installer des addins à partir d’une fenêtre graphique
Installer facilement de nouveaux addins
snippetsaddins: convertir slash automatiquement pour avoir des chemins valide
ggedit: aide pour générer un code pour graphiques ggplot2JADD: en sélectionnant une fonction, on assigne les paramètres par défaut dans l’environnementquestionr: recodage facilité des variables factortrackmd: un outil de track change pour markdownOn peut trouver des aides mémoires en ligne grâce aux cheatsheets. Celle relative à Rstudio est disponible ici
Pour vos yeux fragile, je vous recommande de changer l’aspect de Rstudio pour mettre un fond noir, moins violent 😄. Pour changer le fond, on peut utiliser Tools > Global Options > Appearance↩